Searched hist:"9 fd9f804" (Results 1 – 3 of 3) sorted by relevance
| /xv6-public/ |
| H A D | x86.h | 9fd9f804 Sun Sep 30 14:30:04 GMT 2007 rsc <rsc> Re: why cpuid() in locking code?
rtm wrote:
> Why does acquire() call cpuid()? Why does release() call cpuid()?
The cpuid in acquire is redundant with the cmpxchg, as you said.
I have removed the cpuid from acquire.
The cpuid in release is actually doing something important,
but not on the hardware. It keeps gcc from reordering the
lock->locked assignment above the other two during optimization.
(Not that current gcc -O2 would choose to do that, but it is allowed to.)
I have replaced the cpuid in release with a "gcc barrier" that
keeps gcc from moving things around but has no hardware effect.
On a related note, I don't think the cpuid in mpmain is necessary,
for the same reason that the cpuid wasn't needed in release.
As to the question of whether
acquire();
x = protected;
release();
might read protected after release(), I still haven't convinced
myself whether it can. I'll put the cpuid back into release if
we determine that it can.
Russ
|
| H A D | spinlock.c | 9fd9f804 Sun Sep 30 14:30:04 GMT 2007 rsc <rsc> Re: why cpuid() in locking code?
rtm wrote:
> Why does acquire() call cpuid()? Why does release() call cpuid()?
The cpuid in acquire is redundant with the cmpxchg, as you said.
I have removed the cpuid from acquire.
The cpuid in release is actually doing something important,
but not on the hardware. It keeps gcc from reordering the
lock->locked assignment above the other two during optimization.
(Not that current gcc -O2 would choose to do that, but it is allowed to.)
I have replaced the cpuid in release with a "gcc barrier" that
keeps gcc from moving things around but has no hardware effect.
On a related note, I don't think the cpuid in mpmain is necessary,
for the same reason that the cpuid wasn't needed in release.
As to the question of whether
acquire();
x = protected;
release();
might read protected after release(), I still haven't convinced
myself whether it can. I'll put the cpuid back into release if
we determine that it can.
Russ
|
| H A D | main.c | 9fd9f804 Sun Sep 30 14:30:04 GMT 2007 rsc <rsc> Re: why cpuid() in locking code?
rtm wrote:
> Why does acquire() call cpuid()? Why does release() call cpuid()?
The cpuid in acquire is redundant with the cmpxchg, as you said.
I have removed the cpuid from acquire.
The cpuid in release is actually doing something important,
but not on the hardware. It keeps gcc from reordering the
lock->locked assignment above the other two during optimization.
(Not that current gcc -O2 would choose to do that, but it is allowed to.)
I have replaced the cpuid in release with a "gcc barrier" that
keeps gcc from moving things around but has no hardware effect.
On a related note, I don't think the cpuid in mpmain is necessary,
for the same reason that the cpuid wasn't needed in release.
As to the question of whether
acquire();
x = protected;
release();
might read protected after release(), I still haven't convinced
myself whether it can. I'll put the cpuid back into release if
we determine that it can.
Russ
|